Info-Atari16 Digest Monday, August 21, 1989 Volume 89 : Issue 400 This weeks Editor: Bill Westfield Today's Topics: Re: Multitasking on the ST Re: Multitasking on the ST Re : Names for ST's Re: Meg upgrade. Re: Curses for the ST Re: Meg upgrade. Re: Multitasking on the ST Re: quickst, bigscrn Re: VIP AND KUMA, HOW DO THEY COMPARE? Re: Multitasking on the ST ---------------------------------------------------------------------- Date: 12 Aug 89 16:39:09 GMT From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <482@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM () writes: |In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: [] |>I think two issues are being confused here, the need for per process |>memory protection, and the possible to run processes 'simultaneously'. |>Why should memory protection be a hotter item when parallel processes |>are involved? | |Because of the potential for a single user program to cause the termination |of all the processes in the system. This is equally well possible in the current 'one-process-running-at-a-time' scheme. Note that there are already accessory-based editors, batch modem transfer programs, TSR print spoolers for the ST right now. |Consider: You are a user of the Spiffy multi-tasking-but-no- |per-process-memory-protection Machine. You fire up a ray-trace. [etc. good example left out] | |On a machine with memory protection (OK and resource tracking) the MMU will |prevent corruption of other processes address space, and the nasty process can |be removed from the system cleanly. I think you'll need a bit more than just an MMU for a secure system. S'pose your nasty process alters some system vector (applying patch 271 to SAFEDOS). A pity that the last bug was not yet removed... My point is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE EXCELLENT SYSTEM. That safe system (which undoubtedly will have a notion of privileges, users) is what you should start with in the first place. B.T.W. what do you do when a thunderstorm is coming up, but your raytracer has yet to finish its last hour of calculations? Use a TMU :-) ? [] |I'm all for system robustness for ANY system. My point is that when you |introduce multitasking, memory protection is more important due to the |potential to disrupt other processes. I heard this one before and I still won't believe it, unless a proper argument is given. |>[about VM] | |Sounds Good! But now you're wandering into the area of virtual memory and |that's not what our original discussion was about. Thanks for the reply. You bought an MMU but you don't want VM? Gee, that would be the first reason I would buy an MMU for (and not for protection). As long as the filesystems used are single-user, not write protectable, I don't care much for safe core. Leo. ------------------------------ Date: 12 Aug 89 14:26:05 GMT From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <1989Aug11.175942.6534@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes: |In article <1067@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: [some stuff left out] |> If a process does a call that may involve some time, like |>reading a character from the keyboard (Cconin(), Cnecin()), this |>process only continues its call when there is a character available, so |>it will not unnecessarily block other processes. | |Will you be trapping these interrupts so that you can potentially |unblock tasks waiting on them? Not quite, but to the same effect. What in fact happens, is that before the process enters the real GEMDOS function (the handling of Cconin or whatever) but after its context has been saved on its basepage and stack, the system will look at what process to continue with (of course this could just as well be the same process). Processes that are waiting for some state change like a character from the keyboard becoming available, or the printer being ready to receive further data, are marked that way and will only be selected if the state they're waiting for changes (the test for the changed state is just a simple index comparision in most cases). Calls that can be safely assumed to complete within a reasonable amount of time are not marked waiting (although one could perhaps win something by switching out a process that wants to write to disk when the disk is not yet available). When no waiting processes can be served (no state changes) the other processes are searched for the least served one (processes have a priority and a 'serviced' number). A few problem calls remain: Cconrs(), which reads an entire line from the keyboard. One can at best test for the first character being available, but the user could still take indefinitely to complete his line. Shells that do command line editing, history completion etc. generally won't have a problem, since they typically process their input character by character. A solution would be to rewrite Cconrs() to be re-entrant (no problem since I recently patched Cconrs() to handle a history mechanism, command line editing and file name completion). [] |I must admit the idea sounds like it has merit. However it's easy to |try something like this when blissfully unaware of the pitfalls. The |biggest one I see is that GEMDOS itself is not written to be |re-entrant. Sure, but a) GEMDOS is not being re-entered and b) in a special way, GEMDOS IS re-entrant. After these stunning remarks, I'll have to make myself clear 8-): Consider a series of programs that call each other by a Pexec(), for instance a shell starts make, which starts a compiler, which ... Note that each of them only returns from their Pexec after the Pexec'ed program has finished. That program probably did a lot of GEMDOS calls ---> there you have your re-entrancy (in a special way). The whole trick is that, while one process cannot re-enter GEMDOS (it would at least trash registers left on the basepage for the restore of the previous call), multiple processes can very well all be in a GEMDOS call (they're not yet performing their function, only saved their state). |You will have to be careful when you implement time-slicing that you |do not suspend a process while it is in the midst of a GEMDOS call. [story about semaphores, critical sections left out] But the time-slicing (implemented yesterday evening!) only takes effect when the program was in user mode. This guarantees you're not interrupting any progressing GEMDOS/(X)BIOS/GEM call. Small and beautiful. In fact, my semaphore is the supervisor bit in the program status word! |There are probably thousands of such potential problems. I don't even |want to think about the potential for trashing the disk due to |simultaneous updating... If there is a problem with this scheme, the problem can be reproduced in the current (unmodified) TOS, so it was already there. As for simultaneous updating, each GEMDOS call is completed before the next is done. No trashing. |Still, it sounds like fun to play with. It sure is!! B.T.W. does that sound like an alpha/beta tester :-) ? Cheers, Leo. P.S. The current version screamed for job control, signalling etc. so that's being implemented right now (together with some system calls like signal() and kill()). ------------------------------ Date: 22 Jul 89 20:04:32 GMT From: attcan!utgpu!watmath!watdragon!watcsc!sleeve@uunet.uu.net (Stephen F. White) Subject: Re : Names for ST's To: info-atari16@score.stanford.edu STelllllaaaaaaaaaa!!!! -- /*************************************************************************** * "Rock & Roll vegetable, vegetable stew!" * Stephen F. White, esq. * * - Jazz Butcher * sleeve@watcsc.uucp * ------------------------------ Date: 22 Jul 89 13:32:56 GMT From: mcvax!ukc!icdoc!gould!zmacu06@uunet.uu.net (F S Taylor) Subject: Re: Meg upgrade. To: info-atari16@score.stanford.edu -- | Frank Taylor | Engineers often ponder upon the problem... | | DoC 1 | Why do the girls with the most streamlined shape offer | | Imperial College | the most resistance? anon. | |--------------------+--------+-----------------------------------------------| | JANET: zmacu06@doc.ic.ac.uk | All rights unreserved. | ------------------------------ Date: 22 Jul 89 12:01:35 GMT From: jarvis.csri.toronto.edu!utgpu!watmath!watdragon!tiger!achowe@rutgers.edu (CrackerJack) Subject: Re: Curses for the ST To: info-atari16@score.stanford.edu >Speaking of curses, is there a *real* version of curses available >for the ST? The only "curses" package I've seen is hardcoded for >the ST/VT52 screen only. True curses supports any number of different >terminal types with the termcap database. I know Fred Fish has >written a PD termcap library that will compile on the ST, but I >still haven't seen a real curses yet. There is a curses library/source for ftp on him1.cc.umich.edu. I used this package to port TETRIX about 2 months ago (which has since been posted to the net). - Ant achowe@tiger.waterloo.edu | "Murdered by pirates is good." __ _ | - The Princess Bride (movie) / _ _ _ |/ _ _ | _ _ |/ | \__| `<_\<_ |\|= | ` \_/<_\<_ |\ | disclaimer... ------------------------------ Date: 22 Jul 89 13:58:06 GMT From: mcvax!ukc!icdoc!gould!zmacu06@uunet.uu.net (F S Taylor) Subject: Re: Meg upgrade. To: info-atari16@score.stanford.edu OOOOOOOPs there seems to have been a slight glitch, sorry about the empty posting earlier! :-) I did want to warn people of the dangers of a DIY upgrade (520 --> 1040). I did this very thing. The kit I bought was described in the mag as an easy project that anyone (with a little experience) could do. When the kit arrived it looked fine. In fact the fitting process seemed quite simple, if a little labourious. The problems came when I turned the machine on after re-assembling it. All I got was a blank black screen! After much probing I could not find anything wrong with it so off to the repairers it went. Eventually I got it back working with a full meg, phewww. The main problem with the kit was that you had to solder sockets onto the board. These sat so closely together that it was nigh on impossible to see if two pins had been soldered together (I suspect that this was the problem with mine). So, my advice to anyone trying to upgrade is, unless you *really* know what you are doing when you pick up a soldering iron, get it done by the dealer/upgrade supplier even if it costs 10-15 pounds more. It would have saved me %40 pounds! Frank. -- | Frank Taylor | Engineers often ponder upon the problem... | | DoC 1 | Why do the girls with the most streamlined shape offer | | Imperial College | the most resistance? anon. | |--------------------+--------+-----------------------------------------------| | JANET: zmacu06@doc.ic.ac.uk | All rights unreserved. | ------------------------------ Date: 12 Aug 89 15:55:23 GMT From: attcan!utgpu!watmath!watdragon!dahlia!swklassen@uunet.uu.net (Steven W. Klassen) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <62828@linus.UUCP> rachamp@mbunix (Champeaux) writes: > >Now there's a point to debate. Do you really need memory protection on a >single user multi-tasking computer. On a multi-user computer, memory >protection is a necessity, since if one user's program crashes, you don't >want to bring down the 50 other users. On a personal computer, where cost >is an important factor, is it really necessary? (kind of sounds like the >question "Is multi-tasking really necessary?" doesn't it?) >It would, however, be really nice. Here is a key issue in the multitasking debate: cost vs. performance. While it is true that you are never going to match the performance of a system designed (with hardware) for multitasking only through software, one can come up with some pretty good compromises. Minix is a good example of this, sure its not as secure as Unix but then again, security isn't as much of an issue on a single-user system as it is on a mult-user system. It seems reasonable to sacrifice some security in order to keep cost down and performance up. (Still it would be nice if we had the hardware to make it efficient, but since we don't we must do the best that we can with what we have.) As for the usefulness of multitasking, it extends not just to the end user (running lots of programs), but also to the programmer. Quite often in large applications it is useful to have portions of the system running in the background. Clearly it is more efficient and more secure to have this supported by the OS rather than requiring the program itself to include all the scheduling and security stuff. ie. I would benefit (as a programmer) greatly even if only a limited multitasking were allowed (system calls to provide low priority background processes). Users would benefit from faster running programs since the cpu would not have to be left sitting idle most of the time. Steven W. Klassen Computer Science Major University of Waterloo ------------------------------ Date: 22 Jul 89 19:16:42 GMT From: mcvax!kth!sunic!kullmar!pkmab!daniel@uunet.uu.net (Daniel Deimert) Subject: Re: quickst, bigscrn To: info-atari16@score.stanford.edu In article <512@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: > >an informal survey we (me and Darek) conducted on GEnie showed users wanted >a larger, faster version of Quick ST rather than a smaller, slower version. so >we give them what they want. hell, Turbo ST is 40K. > >quick st can be made to use as little as 10K of memory, but it would be >slower. I agree with them. Why care about 50 kb more or less when you usually got 1 Mb, and at least 512 kb. It's not a very big deal. Rememeber, there're quite a lot of people with four Mb out there... Better this way, make the program bigger and FASTER! Wouldn't an option for use with BLiTTER be nice? (I get better results on scrolling using QuickInf WITHOUT QuickST, but QuickST speeds up the Cconws() etc several times) By the way - someone who knows how to pay these ShareWare-money from Sweden? I can't really send 30$ in an envelope...?! Please e-mail! Daniel Deimert / / Internet: daniel@pkmab.se Fridstav. 4 / / UUCP: ... S-715 94 Odensbacken / / kullmar!pkmab!daniel SWEDEN / / Phone: +46-19-52037, +46-19-111441 (BBS) ------------------------------ Date: 13 Aug 89 00:48:19 GMT From: rochester!rit!ultb!clf3678@rutgers.edu (C.L. Freemesser) Subject: Re: VIP AND KUMA, HOW DO THEY COMPARE? To: info-atari16@score.stanford.edu In article CHIASSA@UDEM.BITNET (Alyre CHIASSON) writes: > > In a number of recent issues of ST WORLD "KUMA" has offered > to VIP users a special price on K-SPREAD 3 plus K-GRAPH 3 if > they send in their master VIP disks. Does anyone have any > experience with either of these "KUMA" products in regards > to what VIP has to offer? Is it worth the switch? Well, I use LOTUS 1-2-3 at work (albeit a summer job). When I come home and boot up VIP, I am given the EXACT SAME environment I have at work. Ergo, VIP is for me! I have never used any other spreadsheet, but if you use LOTUS on any regular basis, VIP is the way to go. Also, you can mooch the LOTUS manuals from work and use them at home. :~) Chris Freemesser, Rochester Institute of Technology | What I like : BITNET: %clf3678@RITVAX GEnie: C.FREEMESSER | 1) My Atari ST USENET: Just reply and hope it gets through | 2) My '77 Mercury | 3) Coke Classic ------------------------------ Date: 13 Aug 89 03:16:34 GMT From: gem.mps.ohio-state.edu!ginosko!rex!hoang@tut.cis.ohio-state.edu (Dzung Hoang) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu For those who would like to experience multitasking on the ST, I would recommend looking at minix ST available from Prentice-Hall for $79. It's a "mini-unix" operating system. Subscribe to comp.os.minix for more info. Dzung Hoang -- ----------------------------------------------------------------------------- hoang@comus.cs.tulane.edu hoang@rex.cs.tulane.edu hoang@comus.UUCP hoang@rex.UUCP tulane!comus!hoang tulane!rex!hoang ------------------------------ End of Info-Atari16 Digest ************************** -------